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Sharing Transaction Fraud Data 
Abstract 
This document describes a document format for exchanging transaction 
fraud (Thraud) information. It extends the Incident Handling Working 
Group (INCH WG) Incident Object Description Exchange Format (IODEF) 
incident reporting document format. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5941. 


M'Raihi, et al. Informational [Page 1] 


RFC 5941 Sharing Transaction Fraud Data August 2010 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


Financial organizations and merchants that offer online access to 
their services frequently encounter fraud perpetrated against their 
customers” accounts. In their attempts to combat these frauds, the 
organizations and their law enforcement agencies could benefit 
greatly by sharing intelligence about fraud incidents and patterns 
with similar organizations and agencies. This specification 
standardizes a document format by which they can share such 
information. It is intended to facilitate multi-vendor 
interoperability between conformant components of an open fraud 
reporting framework. 


Information sharing can take place directly between financial 
organizations and merchants. However, the power of shared 
intelligence is multiplied many times if the information is gathered 
from multiple sources by a shared network, consolidated, and 
redistributed to participants. 


In this arrangement, incident reports submitted to the network are 
called "inbound reports", and reports issued by the network are 
called "outbound reports". 


Inbound reports will be submitted using a push-style protocol (such 
as email or the Simple Object Access Protocol (SOAP)). Outbound 
reports will be distributed using either a push-style protocol or a 
request/response protocol (such as HTTP). 


Inbound reports identify the contributor of the report, as this 
information is essential in evaluating the quality of the information 
it contains and in contacting the source for the purpose of 
clarification. However, outbound reports commonly do not identify 
the original sources, as those sources may not wish to be identified 
to other subscribers. Such reports should, instead, identify the 
consolidator as the source. 


A report may describe a particular transaction that is known to be, 
or believed to be, fraudulent, or it may describe a pattern of 
behavior that is believed to be indicative of fraud. The former type 
of report is called an "activity report" and the latter a "signature 
report". 


The schema defined herein extends the IODEF XML incident reporting 
schema [RFC5070]. 


In Section 3, we introduce the actors in a typical transaction fraud. 
Fraud reporting by means of an IODEF-Document is described in 
Section 4. We define the elements of a Thraud Report in Section 5. 
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In Section 6, we describe the Activity Thraud Report profile of the 
IODEF specification. In Section 7, the profile for a Signature 
Thraud Report is described. In Section 8, we define new attribute 
values for the IODEF Incident class. Security considerations are 
described in Section 9. Section 10 contains IANA considerations 
regarding the registration of the associated media sub-type and XML 
namespace identifier. The Appendices contain the complete XML schema 
and a sample Thraud Report. 


Data elements in this document are expressed in Unified Modeling 
Language (UML) syntax [UML]. 


XML namespace prefixes are used throughout this document to stand for 
their respective XML namespaces, as follows. 


iodef: urn:ietf:params:xml:ns:iodef-1.0 

thraud: urn:ietf:params:xml:ns:thraud-1.0 

xs: http://www.w3.org/2001/XMLSchema 

xsi: http://www.w3.org/2001/XMLSchema-instance 
2. Reguirements Terminology 


The key words "MUST", "MUST NOT", "REOUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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3. Anatomy of a Transaction Fraud 


Sharing Transaction Fraud Data 


August 2010 


The actors in a typical transaction fraud are shown in Figure 1. 


4-——----------------------------------- * 
| Fraudsters | 
| (collect & verify victim credentials | 
| via phishing, malware, etc.) | 
PS SC oo 2 de oa SES GE + 
| 
ina 
| | cn E disburse I SLM 
v v | 
EI Sf + PS ES + To + 
| | | | Fraud | 
| | --Open Dest Acct-->| Financial |---->| Dest. 
| | | Organization | | Account | 
| Fraud | 4-------------- * +------- + 
| Executors | ^ funds 
| transfer 
PS eee + quede * 
| | Victim's | | | 
| |---Init Transfer-->| Financial |<-o--|Victim | 
| | | Organization | | |Account| 
4----------- + 4-------------- + | +------- + 
v 
do + 
| Fraud | 
| Detection | 
| Sensors | 
| (realtime/ | 
| offline) | 
EE E S Es + 


Figure 1. 


Transaction Fraud Elements 


Transaction fraud activities normally involve the following actors: 


1. Fraudsters: 


login credentials using a variety of means, 


and verify them 
Then, 


and malware, 
the victim's account). 


Fraud Executors themselves or wholesale the victims’ 
who will, 


to other Fraudsters, 


M’ Raihi, et al. 


Informational 


individuals or organizations that collect victims’ 


including phishing 

(usually by attempting to log in to 
the Fraudsters may either recruit 
credentials 


in turn, recruit Fraud Executors. 
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2. Fraud Executors: individuals who attempt the fraudulent funds 
transfer or payment. In the case of fraudulent funds transfers, 
an account at either the same financial organization as that of 
the victim or a different one is opened as the destination 
account for the fraudulent transfer. Alternatively, a fraudulent 
payment is made using a check or electronic transfer. 


3. Victims of both credential theft and transaction fraud. 


4. Financial organizations that hold the victim's and the Fraud 
Executor's accounts. 


5. Sensors at the financial organization that detect fraudulent 
transaction attempts, either in real-time or after the fact. 


The intention of Thraud reporting is to enable any organization that 
has detected fraud to share this information, either internally or 
with other potential victim organizations. The receiving 
organization can use this information, for example, to institute 
manual review of transactions initiated from suspicious IP addresses. 


4.  IODEF-Document Incident Class 


A Thraud Report SHALL be an instance of the IODEF-Document class, as 
defined in [RFC5070]. The report SHALL contain at least one Incident 
object, as defined in [RFC5070]. Each Incident object SHOULD contain 
information about a single fraud strategy. One Incident object MAY 
contain information about multiple fraudulent transactions that are 
consistent with the same fraud strategy. Each fraudulent transaction 
SHALL be described in a separate EventData object. The data model 
for the Incident class is defined in [RFC5070] and is repeated here, 
as Figure 2, for the reader's convenience. 
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FT HN + 

| Incident | 

Mc a + 

| ENUM |«»---------- [ IncidentID ] 

| purpose |<>--{0..1}--[ AlternativeID ] 

| STRING |<>--(0..1)--[ RelatedActivity ] 

| ext-purpose |<>--(0..1)--[ DetectTime ] 

| ENUM |<>--{0..1}--[ StartTime ] 

lang <>--(0..1)--[ EndTime ] 

br <>---------- [ ReportTime ] 

| restriction |<>--{0..*}--[ Description ] 

| |<>--{1..*}--[ Assessment ] 

| |<>--(0..*)--[ Method ] 

| |<>--{1..*}--[ Contact ] 

| |<>--{1..*}--[ EventData ]<>--[ AdditionalData ] 
<>--(0..1)--[ History ] 
<>--(1..*)--[ AdditionalData |] 

do —— + 


Figure 2. Data Model of the Incident Class 


The AdditionalData abstract class is an extension point in the schema 
of the EventData class.  Implementers SHALL include exactly one of 
the following objects in AdditionalData: FraudEventPayment, 
FraudEventTransfer, FraudEventIdentity, or FraudEventOther. 
Collectively, these are known as Thraud Records. The corresponding 
classes are defined by this specification in Section 5, below. 


The Thraud profile of the Incident class is defined in Sections 6 and 
7, below. 


5. Thraud Record Class Definitions 


Thraud Records are expressed in XML. Therefore, the dtype attribute 
of the AdditionalData element SHALL be assigned the value "xml". 


A payment Thraud Record SHALL be structured as shown in Figure 3. 
See also Section 5.1. 


R------------------ * 
| AdditionalData | 
4R------------------ * 
| ENUM dtype (xml) |«»----- [ FraudEventPayment ] 
4R------------------ * 
Figure 3. The FraudEventPayment Extension 
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A funds-transfer Thraud Record SHALL be structured as shown in 


Figure 4. See also Section 5.2. 
dem mm mm mm mm mm —— + 
| AdditionalData | 
dem mm mm mm mm mm mm ——— + 
| ENUM dtype (xml) |<>----- [ FraudEventTransfer ] 
dem  c[ + 
Figure 4. The FraudEventTransfer Extension 


An identity Thraud Record SHALL be structured as shown in Figure 5. 
See also Section 5.3. 


ee le i + 
| AdditionalData | 
+------------------ + 
| ENUM dtype (xml) |«»----- [ FraudEventIdentity ] 
+------------------ + 


Figure 5. The FraudEventIdentity Extension 


Other Thraud Records SHALL be structured as shown in Figure 6. See 
also Section 5.4. The FraudEventOther class has an open definition 
to act as a placeholder for event types that emerge in the future. 


4------------------ + 
| AdditionalData | 
4------------------ + 
| ENUM dtype (xml) |<>----[ FraudEventOther ] 
4------------------ + 
Figure 6. The FraudEventOther Extension 


5.1. FraudEventPaymentType Class 


The FraudEventPaymentType class is used to report payee instructions 
for a fraudulent payment or fraudulent payment attempt. 
sometimes use the same payee instructions 
multiple fraudulent payment attempts. By reporting the payment 
instructions used in the fraud, other organizations may be able to 
detect similar fraudulent payment attempts to the same payee. 


Fraudsters 
(including the amount) for 


The structure of the FraudEventPaymentType class SHALL be as shown in 
Figure 7. 
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4------------- + 

| FraudEvent- | 

| PaymentType | 

4------------- + 

| |<>--(0..1)--[ PayeeName ] 

| |<>--{0..1}--[ PostalAddress ] 
| |<>--{0..1}--[ PayeeAmount ] 
4------------- + 


Figure 7. The FraudEventPaymentType Class 


The contents of the FraudEventPaymentType class are described below. 
At least one component MUST be present. 


5.1.1. PayeeName 
Zero or one value of type iodef:MLString. The name of the payee. 
5.1.2. PostalAddress 
Zero or one value of type iodef:MLString. The format SHALL be as 
documented in Section 2.23 of [RFC4519], which defines a postal 
address as a free-form multi-line string separated by the "$" 
character. 
5.1.3. PayeeAmount 
Zero or one value of type thraud:AmountType. See Section 5.5. 


5.2.  FraudEventTransferType Class 


The FraudEventTransferType class is used to report the payee 
instructions for a fraudulent funds transfer or fraudulent funds 


transfer attempt.  Fraudsters sometimes use the same payee 
instructions (including the amount) for multiple fraudulent funds 
transfer attempts. By reporting the funds transfer instructions used 


in the fraud, other organizations may be able to detect similar 
fraudulent funds transfer attempts to the same payee. 


The structure of the FraudEventTransferType class SHALL be as shown 
in Figure 8. 


M'Raihi, et al. Informational [Page 10] 


RFC 5941 Sharing Transaction Fraud Data August 2010 


$ + 

| FraudEvent- | 

| TransferType | 

R-—------------ * 

| |<>--(0..1)--[ BankID ] 

| |<>--{0..1}--[ AccountID ] 

| |<>--{0..1}--[ AccountType ] 

| |<>--{0..1}--[ TransferAmount ] 
$ + 


Figure 8. The FraudEventTransferType Class 


The contents of the FraudEventTransferType class are described below. 
At least one component MUST be present. 


5.2.1. BankID 
Zero or one value of type thraud:BankIDType. The structure of the 
BankIDType class SHALL be as shown in Figure 9. The contents SHALL 
be of type xs:string. The namespace attribute SHALL be of type 


XS:anyURI and SHALL identify the numbering system used to identify 
the bank or account. 


| STRING | 


STRING namespace 


Figure 9. The BankIDType Class 
A list of registered namespace identifiers is maintained at: 


http: //www.openauthentication.org/thraud/resources/bank-id- 
namespace.htm 


The following namespace attribute values and their semantics are 
registered. 


One of the nine-digit Routing Numbers registered to the financial 
organization that holds the account, as administered by The American 


Bankers Association. 


http: //www.openauthentication.org/thraud/resources/bank-id- 
namespace.htmttamerican_bankers_association 
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The three-digit Institution Number registered to the financial 
organization that holds the account, as administered by The Canadian 
Payments Association. 


http: //www.openauthentication.org/thraud/resources/bank-id- 
namespace.htmitcanadian_payments_association 


The corresponding AccountID represents the ISO 13616 International 
Bank Account Number [ISO13616-1:2007] in the "electronic form" (i.e., 
containing no spaces) that is assigned to the account, as 
administered by the Society for Worldwide Interbank Financial 
Telecommunication (SWIFT). The corresponding BankID xs:string value 
SHOULD be set to the null string. Receiving organizations SHOULD 
ignore the corresponding BankID value. 


http://www.openauthentication.org/thraud/resources/bank-id- 
namespace.htmtiso13616 1 2007 


The eight-character Bank Identifier Code [1SO9362:1994] registered to 
the financial organization that holds the account, as administered by 


SWIFT. 


http://www.openauthentication.org/thraud/resources/bank-id- 
namespace.htmtiso9362 1994 


Other namespace values MUST be agreed upon among participants. 
Requests to register nev values SHOULD be made at: 


http://www.openauthentication.org/thraud/form/bank-id-namespace 


Note that a single organization may be identified by more than one 


value for any one or more of these namespaces. Therefore, receiving 
organizations SHOULD take this into account in their matching 
procedure. 


5.2.2. AccountID 


Zero or one value of type xs:string. The destination primary account 
number, as administered by the financial organization identified in 
the BankID element. In the case where the BankID namespace attribute 
value is "iso13616 1 2007", this element SHALL contain the 
International Bank Account Number in the "electronic form" (i.e., 
containing no spaces) that is assigned to the account. In all other 
cases, the element SHALL contain only the account number, as 
administered by the financial organization that holds the account. 
The reporting organization SHALL remove all prefixes that identify 
the country, bank, or branch. 


M'Raihi, et al. Informational [Page 12] 


RFC 5941 Sharing Transaction Fraud Data August 2010 


5.2.3. AccountType 
Zero or one value of type thraud:AccountTypeType. See Section 5.6. 
5.2.4.  TransferAmount 
Zero or one value of type thraud:AmountType. See Section 5.5. 
5.3. FraudEventIdentityType Class 
The FraudEventIdentityType class is used to report a fraudulent 
impersonation or fraudulent impersonation attempt. By reporting the 
impersonation event, other potential victims may be able to detect 


Similar fraudulent impersonation attempts. 


The structure of the FraudEventIdentityType class SHALL be as shown 
in Figure 10. 


4-------------- + 
| FraudEvent- | 
| IdentityType | 
4-------------- + 
| |<>--{1..*}--[ IdentityComponent ] 
4-------------- + 


Figure 10. The FraudEventIdentityType Class 
The contents of the FraudEventIdentityType class are described below. 
5.3.1.  IdentityComponent 


One or more values of type iodef:ExtensionType. This specification 
defines two extensions: EmailAddress and UserID. 


5.3.1.1. EmailAddress 


In reporting an identity fraud event, the reporting institution MAY 
include the victim's email address. This SHALL be achieved by 
placing an object of type iodef:Email in the IdentityComponent 
object. It SHALL contain the email address of the intended fraud 
victim. 


The IdentityComponent.dtype attribute SHALL be set to the value 
"String". 


The IdentityComponent.meaning attribute SHALL be set to the value 
"victim email address". 


M'Raihi, et al. Informational [Page 13] 


RFC 5941 Sharing Transaction Fraud Data August 2010 


5.3.1.2. UserID 


In reporting an identity fraud event, the reporting institution MAY 
include the victim's user identifier. This SHALL be achieved by 
placing an object of type iodef:ExtensionType in the 
IdentityComponent object. The data type of the extension contents 
SHALL be xs:string. It SHALL contain the user identifier of the 
intended fraud victim. 


The IdentityComponent.type attribute SHALL be set to the value 
"String". 


The IdentityComponent.meaning attribute SHALL be set to the value 
"victim user id". 


5.4. FraudEventOtherType Class 


The FraudEventOtherType class SHALL be used to report fraudulent 
events other than those detailed above, such as new event types that 
may emerge at some time in the future. This class enables such 
events to be reported, using this specification, even though the 
specific characteristics of such events have not yet been formally 
identified. By reporting the details of these unspecified event 
types, other institutions may be able to detect similar fraudulent 
activity. 


The structure of the FraudEventOtherType class SHALL be as shown in 


Figure 11. 

4------------- t 

| FraudEvent- | 

| OtherType | 

4------------- t 
<>---------- [ OtherEventType ] 
<>--(0..1)--[ PayeeName ] 

| |<>--(0..1)--[ PostalAddress ] 

| |<>--{0..1}--[ BankID ] 

| |<>--(0..1)--[ AccountID ] 

| |<>--(0..1)--[ AccountType ] 
<>--(0..1)--[ PayeeAmount ] 
<>--(0..1)--[ OtherEventDescription |] 

4------------- t 


Figure 11. The FraudEventOtherType Class 
Many of the components of the FraudEventOtherType class are also 


components of the FraudEventPaymentType or FraudEventTransferType 
classes. Their use in the FraudEventOtherType class is identical to 
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their use in those classes. Therefore, their descriptions are not 
duplicated here. Only components that are unique to the 
FraudEventOtherType class are described below. 


5.4.1. OtherEventType 
One value of type xs:anyURI. A name that classifies the event. 
A list of registered "other event type" identifiers is maintained at: 


http://www.openauthentication.org/thraud/resources/other-event- 
type.htm 


Requests to register new values SHOULD be made at: 
http://www.openauthentication.org/thraud/form/other-event-type 
5.4.2. OtherEventDescription 


Zero or one value of type iodef:MLString. A free-form textual 
description of the event. 


5.5.  AmountType Class 


The AmountType class SHALL be as shown in Figure 12. It SHALL be 
used to report the amount of a payment or transfer fraud. 


| DECIMAL | 


| STRING currency | 


Figure 12. The AmountType Class 
The contents of the AmountType class are described below. 
5.5.1. Class Contents 
REQUIRED DECIMAL. The amount of the payment or transfer. 


5.5.2. Currency 


REQUIRED STRING. The three-letter currency code [1S04217:2008]. 
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5.6. AccountTypeType Class 


The AccountTypeType class SHALL be as shown in Figure 13. It SHALL 
be used to report the type of the destination account. 


STRING 


| STRING lang | 


Figure 13. The AccountTypeType Class 


Receiving organizations MUST be capable of processing contents 
containing spelling variations. 


6. IODEF Profile for an Activity Thraud Report 


This section describes the profile of the IODEF Incident class for a 
compliant Activity Thraud Report. 


6.1. Mandatory Components 


A Thraud Report SHALL conform to the data model specified for an 


IODEF-Document in [RFC5070]. The following components of that data 
model, while optional in IODEF, are REQUIRED in a conformant Thraud 
Report. 


Receiving organizations MAY reject documents that do not contain all 
of these components. Therefore, reporting organizations MUST 
populate them all. 


Except where noted, these components SHALL be interpreted as 
described in [RFC5070]. 


Incident.Contact.ContactName - The name of the reporting 
organization. In case the reporting organization acts as a 
consolidator of reports from other organizations, elements of this 
class SHALL contain the name of the consolidator. 

Incident.Contact.Email - An email address at which the reporting 
organization may be contacted. 

Incident.Contact.Telephone 

Incident.EventData 

Incident.EventData.AdditionalData - SHALL contain exactly one Thraud 
Record. 
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6.2. Recommended Components 


Receiving organizations SHOULD be capable of processing the following 
components. However, they MUST NOT reject documents because they are 
either present or absent. 


If available, reporting organizations SHOULD include these components 
in Thraud Reports. Except where noted, these components SHALL be 
interpreted as described in [RFC5070]. 


Incident.Contact.Contact 

Incident.Contact.Contact.ContactName - The name of the reporting 
fraud analyst. 

Incident.Contact.Contact.Email - The email address of the reporting 
fraud analyst. 

Incident.Contact.Contact.Telephone - The telephone number of the 
reporting fraud analyst. 

Incident.EventData.Method 

Incident.EventData.Method.Description 

Incident.Assessment.Confidence 

Incident.Assessment.Impact 

Incident.Assessment.MonetaryImpact 

Incident.EventData.DetectTime 

Incident.EventData.StartTime 

Incident.EventData.EndTime 

Incident.EventData.Flow 

Incident.EventData.Flow.System 

Incident.EventData.Flow.System.Service 

Incident.EventData.Flow.System.Node.NodeName 

Incident.EventData.Flow.System.Node.Address 


6.3. Deprecated Components 


This profile provides no guidance to receiving organizations on the 
proper processing of the following components. Therefore, the 
reporting organization has no assurance that the receiving 
organization will handle them in an appropriate manner and SHOULD NOT 
include them in a Thraud Report. However, receiving organizations 
MUST NOT reject reports that do contain these components. 


Incident .DetectTime 
Incident .AlternativeID 
Incident .RelatedActivity 
Incident.StartTime 
Incident .EndTime 
Incident .ReportTime 
Incident .Description 
Incident .Method 


M’Raihi, et al. Informational [Page 17] 


RFC 5941 


Incident 
Incident 
Incident 


Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
Incident 
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. History 
.AdditionalData 
.ext-purpose 
Incident. 
.Contact.Description 

.Contact .RegistryHandle 

.Contact .PostalAddress 

.Contact .Fax 

.Contact . TimezZone 

.Contact .AdditionalData 

.Contact .Contact .Description 

.Contact .Contact .RegistryHandle 
.Contact.Contact.PostalAddress 
.Contact.Contact.Fax 
.Contact.Contact.TimeZone 

.Contact .Contact .AdditionalData 
.Contact.ext-role 

.Contact.ext-type 
.Contact.Contact.ext-role 
.Contact.Contact.ext-type 
.EventData.Method.Reference 
.EventData.Method.Reference.Description 
.EventData.Method.AdditionalData 
.EventData.Method.Reference.URL 
.Assessment.TimeImpact 
.Assessment.AdditionalData 
.Assessment. Impact .type 
.EventData.Description 
.EventData.Contact 
.EventData.Assessment 
.EventData.Expectation 
.EventData.Record 

.EventData.EventData 
.EventData.Flow.System.OperatingSystem 
.EventData.Flow.System.Counter 
.EventData.Flow.System.Description 
.EventData.Flow.System.AdditionalData 
.EventData.Flow.System.ext-category 
.EventData.Flow.System.Node.Location 
.EventData.Flow.System.Node.DateTime 
.EventData.Flow.System.Node.NodeRole 
.EventData.Flow.System.Node.Counter 
.EventData.Flow.System.Node.Address.ext-category 
.EventData.Flow.System.Service.ProtoType 
.EventData.Flow.System.Service.ProtoCode 
.EventData.Flow.System.Service.ProtoField 
.EventData.Flow.System.Service.Application 
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7. IODEF Profile for a Signature Thraud Report 


A Signature Thraud Report SHALL convey information about the behavior 
associated with fraudulent events, rather than reporting the details 
of the specific events themselves. 


Sharing Signature Thraud Reports helps receiving organizations to 
detect suspicious behavior in their own systems. 


A Signature Thraud Report SHALL conform to the profile described in 
Section 6. 


8. IODEF Additional Attribute Values 
Additional IODEF attribute standard values are defined here. 
8.1. Purpose Attribute 


The following additional values are defined for the Incident.purpose 
attribute. 


Add - The enclosed Thraud Record values SHOULD be added to the corpus 
by the receiving organization. 


Delete - The enclosed Thraud Record types SHOULD be deleted from the 
corpus by the receiving organization. 


Modify - The enclosed Thraud Record values SHOULD replace the 
corresponding values in the corpus. Where no corresponding types 
currently exist in the corpus, the enclosed values SHOULD be added to 
the corpus by the receiving organization. 


9. Security Considerations 


This document describes a document format for exchanging information 
about successful or attempted transaction and authentication fraud 
incidents. The information is intended to be used to improve the 
effectiveness of participants' fraud detection and prevention 
programs. The effectiveness of such programs depends critically on 
the accuracy, reliability, confidentiality, and timeliness of both 
the information and the participants in its exchange. Threats to 
accuracy, reliability, and confidentiality include (but are not 
limited to) those described here. 


Fraudsters may attempt to introduce reports that delete or modify 
incident information in the corpus. Therefore, origin authentication 
MUST be employed. Human review SHOULD be performed prior to 
implementing modifications to the corpus. 
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Fraudsters may attempt to interrupt or redirect submissions, thereby 
preventing the sharing of intelligence concerning their fraud 
strategies. Therefore, authenticated receipts SHOULD be employed. 


Fraudsters may attempt to impersonate legitimate submitters, thereby 
poisoning their reputations and rendering ineffective their future 
submissions. Origin authentication MUST be used to ensure that the 
sources of reports are properly identified. 


Fraudsters that can view incident reports may adapt their fraud 
strategies to avoid detection. Therefore, reports MUST be protected 
by confidentiality services including transport encryption and access 
control. 


In order to prevent inadvertent disclosure of incident data, incident 
reports SHOULD be encrypted while in storage. 


The submitter of an incident report may incorrectly identify 
legitimate activity as a fraud incident. This may lead to denial of 
service by a receiving organization that relies on the report or 
information derived from the report. Receiving organizations SHOULD 
operate a reputation service, in which the reliability of the 
information from particular sources is assessed and tracked and 
subsequent reports are weighted accordingly. The source of reports 
MUST be authenticated. Receiving organizations SHOULD use reports to 
step up authentication assurance, rather than simply denying service. 


A receiving organization may misuse a Thraud Report to deny service, 
resulting in a loss for a legitimate user. If such a user were to 
learn the identity of the source of the information that led to the 
denial of service, then that source may become implicated in any 
resulting claim for compensation. This, in turn, may discourage 
reporting organizations from participating in intelligence sharing. 
Therefore, original sources SHOULD NOT be identified in consolidated 
reports. 


Any origin authentication and data integrity mechanism that is 
acceptable to both parties MAY be used. 


Any transport confidentiality mechanism that is acceptable to both 
parties MAY be used. 


This specification does not include a data compression technique. 


Therefore, it does not introduce any denial of service 
vulnerabilities related to decompression. 
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10. 


10. 


IANA Considerations 
This specification registers two identifiers: 


o The media sub-type name "thraud+xml" in the standard registration 
tree. 


o The xml namespace identifier - urn:ietf:params:xml:ns:thraud-1.0. 
1. Media Sub-Type 

Type name: application 

Subtype name: thraudrxml 

Required parameters: none 


Optional parameters: "charset": same as the charset parameter of 
application/xml, as specified in [RFC3023]. 


Encoding considerations: same as encoding considerations of 
application/xml, as specified in [RFC3023]. 


Security considerations: in addition to the security considerations 
described in Section 9, this registration has all of the security 
considerations described in [RFC3023]. 


Interoperability considerations: None beyond the interoperability 
considerations described in [RFC3023]. 


Published specification: the media type data format is defined in RFC 
5941. 


Applications that use this media type: transaction and authentication 
fraud analysis and reporting applications, and risk-based 
transaction and authentication evaluation applications. 


Additional information 
Magic number(s): none 
File extension: .tfi 
Macintosh file type codes: none 


Person and email address to contact for further information: 
"D M'Raihi <davidietf@gmail.com>" 


Intended usage: LIMITED USE 
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Restrictions on usage: thraud media are intended for no usage other 
than the exchange of fraud intelligence data. 
Author: D M'Raihi 
Change controller: the IESG 
10.2. XML Namespace 
IANA has registered the xml namespace identifier: 
URI: urn:ietf:params:xml:ns:thraud-1.0 
Registrant Contact: 
Siddharth Bajaj 
VeriSign, Inc. 
487 E. Middlefield Road 
Mountain View, CA 94043 
USA 
Email: sbajaj@verisign.com 
XML: None. Namespace URIs do not represent an XML specification. 
11. Conclusion 
This specification introduces a transaction fraud (Thraud) reporting 
document structure that enables the sharing of fraud data. Based on 


the IODEF-Document format, the proposed extension facilitates 
interoperability to increase the security of online applications. 
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Appendix A.  Thraud Record XML Schema 


«?xml version="1.0" encoding-"UTF-8"?» 
«xs:schema targetNamespace-"urn:ietf:params:xml:ns:thraud-1.0" 
xmlns:thraud-"urn:ietf:params:xml:ns:thraud-1.0" 
xmlns:xs-"http://www.w3.org/2001/XMLSchema" 
xmlns:iodef-"urn:ietf:params:xml:ns:iodef-1.0" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 
<xs: import namespace-"urn:ietf:params:xml:ns:iodef-1.0" 
schemaLocation=" 
http: //www.cert.org/ietf/inch/schema/rfc5070.xsd"/> 
<xs:element name="FraudEventPayment" 
type-"thraud:FraudEventPaymentType"/» 
«xs:element name-"FraudEventTransfer" 
type-"thraud:FraudEventTransferType"/» 
<xs:element name-"FraudEventIdentity" 
type-"thraud:FraudEventIdentityType"/» 
«xs:element name-"FraudEventOther" 
type-"thraud:FraudEventOtherType"/» 
«xs:complexType name-"FraudEventPaymentType"» 
<xs:seguence> 
<xs:element name="PayeeName" type="iodef:MLStringType" 
minOccurs-"0"/» 
«xs:element name-"PostalAddress" type-"iodef:MLStringType" 
minOccurs-"0"/» 
«xs:element name-"PayeeAmount" type-"thraud:AmountType" 
minOccurs-"0"/» 
«/xs:sequence» 
«/xs:complexType» 
«xs:complexType name-"FraudEventTransferType"» 
<xs:sequence> 
<xs:element name="BankID" type="thraud:BankIDType" 
minOccurs="0"/> 
<xs:element name-"AccountID" type-"xs:string" minOccurs="0"/> 
<xs:element name="AccountType" type="iodef:MLStringType" 
minOccurs="0"/> 
<xs:element name="TransferAmount" type="thraud:AmountType" 
minOccurs="0"/> 
</xs:sequence> 
</xs:complexType> 
<xs:complexType name-"FraudEventIdentityType"> 
<xs:seguence maxOccurs-"unbounded"> 
<xs:element name-"IdentityComponent" 
type="iodef:ExtensionType"/> 
</xs:sequence> 
</xs:complexType> 
<xs:complexType name="FraudEventOtherType"> 
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<xs:seguence> 
<xs:element name-"OtherEventType" type-"xs:anyURI"/> 
<xs:element name="PayeeName" type-"iodef:MLStringType" 
minOccurs-"0"/» 
«xs:element name-"PostalAddress" type-"iodef:MLStringType" 
minOccurs-"0"/» 
«xs:element name-"BankID" type-"thraud:BankIDType" 
minOccurs-"0"/» 
«xs:element name-"AccountID" type="xs:string" minOccurs-"0"/» 
«xs:element name-"AccountType" type-"iodef:MLStringType" 
minOccurs-"0"/» 
<xs:element name="PayeeAmount" type-"thraud:AmountType" 
minOccurs-"0"/» 
«xs:element name-"OtherEventDescription" 
type-"iodef:MLStringType" minOccurs-"0"/» 
«/xs:sequence» 
«/xs:complexType» 
«xs:complexType name-"AmountType"» 
<xs:simpleContent> 
<xs:extension base="xs:decimal"> 
<xs:attribute name="currency" type="xs:string"/> 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 
<xs:complexType name="BankIDType"> 
<xs:simpleContent> 
<xs:extension base="xs:string"> 
«xs:attribute name="namespace" type="xs:anyURI" 
use-"required"/» 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 
<xs:element name-"UserID" type="xs:string"/> 
</xs:schema> 
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Appendix B. Example of a Thraud Report 


«?xml version="1.0" encoding-"UTF-8"?> 
«IODEF-Document xmlns-"urn:ietf:params:xml:ns:iodef-1.0" 
xmlns:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation-"urn:ietf:params:xml:ns:iodef-1.0" 
lang="en"> 
<Incident purpose="reporting"> 
<IncidentID name="fraud.openauthentication.org">908711 
«/IncidentID» 
<ReportTime>2006-10-12T00:00:00-07:00</ReportTime> 
<Assessment> 
<Impact severity="high" completion="failed"/> 
<Confidence rating="high"/> 
</Assessment> 
<Contact type="organization" role="creator"> 
<ContactName>Example Corp.</ContactName> 
<Email>contact@example.com</Email> 
<Telephone>+1.972.555.0150</Telephone> 
</Contact> 
<EventData> 
<DetectTime>2006-10-12T07:42:21-08:00</DetectTime> 
<Flow> 
<System category-"source"> 
<Node> 
<Address category-"ipv4-addr">192.0.2.53</Address> 
</Node> 
<Description>Source of numerous attacks</Description> 
</System> 
</Flow> 
<AdditionalData dtype-"xml"» 
<FraudEventTransfer xmlns-"urn:ietf:params:xml:ns:thraud- 
1.0" xmlns:iodef—"urn:ietf:params:xml:ns:iodef-1.0" 
xmlns:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation-"urn:ietf:params:xml:ns:thraud-1.0"» 
«BankID 
namespace-"http://www.openauthentication.org/thraud/resources/ 
bank-id-namespace.htm#american_bankers_association">123456789</BankID> 
<AccountID>3456789</AccountID> 
<AccountType lang-"en">saving</AccountType> 
<TransferAmount currency-"USD">10000</TransferAmount> 
</FraudEventTransfer> 
</AdditionalData> 
</EventData> 
</Incident> 
</IODEF-Document> 
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